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INTROOUCTION 


This document describes the functions and proposed lapfementation 
of a scheduler for Multics which witt atfltow more fiexlibie 
administrative contrat of the allocation of the cpu time resource 
to system users and groups of users. 


It is not an objective of this proposal to attempt to achieve 
greater throughput in any numerical sensee However; it is an 
explicit objective that throughput of Jobs deemed most vatuable 
by a system administrator will be increased. To that extent, the 
value of Multics as a computer utltity is enhanced. Of course, 
every effort will be made to ensure the efficiency of the deslgn 
and isaplementation of the priority scheduler. 


THE PROBLEM 


Currentiy, the Answering Service provides a mechanism (toad 
control) for classifying users Into groups: and glving each group 
a specified share of the system (by ftimiting the number of users 
from each group that may be fogged in concurrentiy). 


However, except for the setting of the per-process parameter, 
timaxse no control over the rate of consumption of cpu resources 
by any user or group of users is provided. (Briefly stated, 
there is a parameter, tis associated with each process, which is 
roughty proportional to the amount of cpu time used by the 
process since it tast Interacted. If the vaiue of tl for a 
process ever exceeds timax, it is set to timax. The process wlth 
the towest value of ti is always selected for eligibitity.) In 
practice, the considerable advantage given to a process by a 
fower-than-normal vatue of timax has prevented all processes but 
the Initialtizer (and sometimes Backup} from being given timax*s 
flower than the default value. 


THE SOLUTION 


This MTB proposes that the scheduter altow the grouping of 
processes Into work classes, and provide each work class alth a 
guaranteed percentage of availabie cpu time. Conceptualiy,. each 
work class wlll be assigned a virtual processor of 
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administratively defined computational power, available to 
members of the appropriate work class on demand. Any cpu time 
net needed ov a work class will be made avaitable to other work 
classes, and cannot be recitaimed at 2 tater time. In this 
respect each virtual processor is tike a real processort time 


unused is time tost forever. 


In its idealized form, the scheduler proposed here provides each 
work class with a specified computatlonalt power on an 
Instantaneous basis. The idealized scheduler has a time constant 
(or integrating tlme) approaching zero seconds. The service and 
functlon provided by the ideatized scheduler are known constants, 
not subject to being bent out of shape by previous transients in 
per-workclass loads. 


The actuat scheduler wlltt for reasons of system efficiency, 
scheduler efficiency and response, necessarily have a time 
constant on the order of several seconds. As an example, 
consider the time constant required to smoothly provide service 
to a work class which has been assigned 20 percent of a single 
cpu configuration and whose members are generally provided with 
an etiglbility quantum of 2 seconds. If the scheduler functlons 
correctly, some process in the work class will be glven aetwo 
virtual second quantum every i0 virtual seconds, or approximately 
every 20 real secondse Thls impties that In some way fhe 
schedufer must be Integrating over the past 20 real seconds’ for 
such a work classe Averaging over a conslderably shorter perlod 
would require significantly shorter quanta and result in 
Increased scheduler and paging overhead. Averaging over tonger 
periods of time moves away from the Idealtized scheduler and 
toward a schedujer whose behavior IS more dependent than 
necessary on the past history of the system. 


The ability to Jtimit the number of processes in each work class 
Is clearty desirable, if not an absolute necessity, and the 
abllity to assign each process to a speclfic work class Is 
obviousty needed. 


To have two separate and independently-functloning mechanisms for 
classlfying users Into groups and timiting the number from each 
group that may be logged In concurrentiy Is at best unnecessary, 
and at worst, confusing and full of nidden probtems. 


Therefore, there must be a close retlationsnip between work 
classes and load control groups», and a single aigorithm must be 
used to determine a process*s membership in both classifications. 
For example, there coutd either be a one-fo-one correspondence 
between work classes and load control groups, or else the work 
ciass of a process could be a function of Its toad control group, 
with posslibly more than one toad control group belonging to one 
work clasSe We have chosen the fatter, more general, 
alternative. 
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It wilt! be possibie for the system administrator to specify the 
number of work classes (a !imit of 16 wll! f be Imposed by the 
scheduler). and the guaranteed percentage of each work class. 


The administrator will be able to define the membership of each 
work classe It wili be possible to define such work classes as3 
afl I0 daemons, the BSackup daemon, aii users ona certain 
project, or one individual user. In each of those groupings, if 
wlll be possibile to assign absentee and Interactive processes 
either to the same or to different work classes. 


The set of work class parameters, and the membership of each will 
be able to be changed automaticaity (at each shift change) = and 
manuatiy (by the system administrator, who may install a new 
tabie at any time). Thus, the work classes of existing processes 
can changee 


HARDCORE SCHEDULER 


The new scheduler will maintain an eilglbie queue consisting of 
eligible processes only and wiil manage 16 ready queues, one for 
each work class. Each ready queue will be managed Just as the 
non-etlgibie portion of the current ready queue is managed --- 
that is the queues will each be internally sorted by ti values 
and favor the most interactive users within the work class. The 
current method of maintaining a ready queue Is chosen for the nen 
scheduler for three reasons? 


1. It is response orlented, and in fact thas been proven to 
provide the minimum mean respose time. 


2e If such a queue consists of processes all with tl = timax, 
the the queue Is targety run as a pushdown stack. This 
teads to very desirable paging behavior in that the most 
recentiy run process (the process most likely to have its 
working set stili in core or on the paging device) wlil 
often be the nexf process to be rune 


3e Use of already existing code wit simptify the 
irmplementation effort required. 


To contain information. pertaining to each work class, tc_data 
wlll contain 16 work _class_tabdlie_entries (WCTE*s). Each WCTE 
wliit contain a thread-word for accessing the members of the work 
class which are ready,» and att parameters and metering data 
relating to the work classe This wilt! Inctude the total amount 
of virtuat cpu time used by the work class, fhe totai number. of 
times etligibitity was granted to a member, the fraction of 
virtual cpu time which the work class Is ta receive, and the 
response time seen by ifs members. 
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Tne actual algorithm used to enforce the proper sharing of the 
cpu resource will be as follows. Imagine the existance of a 
System wirtual cieock which Increments as virtual time is used by 
non-lIdie processes. Imagine also that each work class has a 
store of credits (in units of microseconds) which is continualty 
growing at a rate proportional to the speed of the virtual clock 
multiplied by the fraction of cpu resources which the work class 
is to recelve. Suppose further that the store of credits for the 
work ciass is decremented as members actualty consume virtual cpu 
time. Clearty it is undesirable to aitow credits to build up 
indefinitely for a work class with no processes ready, so a 
maximum value is set on the number of credits which can be 
accumulated. In addition the vatue is restricted from ever 
becoming negative. The algorithm for choslng the next work class 
from which to choose a process to which to award eliglbllity may 
then be as simpie as choosing that work class which has 
accumulated the maximum number of credits. 


A worthwhite refinement would be to choose the work class for 
which the ratio of the number of credits to the quantum to be 
awarded (ie. to the top member of the given ready queue) is a 
maximum. This tends to favor the prompt scheduling of the most 
Interactlve users across ail work classes. It does not cause 
non-interactive work classes to fall far behind since eventually 
the interactive work ciasses choke off. This is because they are 
temporarlly using credits faster than they are gaining them, and 
wlll eventually nave a ratio which Is arbitrarily tow --- and not 
be chosen. 


It follows that the maximum build up of credits to be allowed 
must be greater than the maximum quantum allowed. It should 
probably be at teast double that amount. 


The computation requlred for such an algoritha wltt amount = to 
about 300 microseconds per eligibility granted, fess If fener 
than 16 work classes are defined. If eligibllity Is awarded 10 
times per second (a high figure) on a one cpu configuration, the 
foss in system throughput may be about .3Z. This is somewhat 
reduced by the fact that alti sorting operations Into the ready 
queue wlll be replaced by sorts into shorter queues. 


HARDCORE INTERFACE 
The Interfaces to the hardcore scheduler will be the foltowing? 


1. A gate to define (or redefine) the set of work classes and 
thelr guaranteed percentages of cpu time. This gate is 
tentatively caltted nphcs_S$define_work_classes. The target 
of this gate witt. be a new procedure (tc.pli) which alii 
check the consistancy of its arguments, use existing 
subroutines to wire and masks and tock the APT before 
modifying the work class tabfe. Because thls procedure witli 
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not be heavily used it wilt) cati  wire_proc$wire_me rather 
than belng permanently wired. It will be {Ltlegali to 
undefine a work class that currently has processes in Ite 
If that is attempted, the processid and work class number of 
one of the “offending” processes wili be returned, In order 
that appropriate action can be taken. 


2< A gate to reassign one existing process to a different work 
class. It will! refuse to change the work class if the new 
one is not defined. It Is tentatively called 
hohcs_8set_process_work_ciasse The target of this gate will 
be pxss$set_ work class. 


3. An additional parameter in the create_info structure passed 
to hphcs_$create_proc: the initia! work class. It will be 
litegal to specify a work class that Is not defined. tt 
will be necessary for act _proc, the tar get of 
hphcs_$create_proc, to cal! pxss8sef_work_class, to Insure 
that the work class being assigned to the new process 
currentiy existse 


A primitive to simultaneously redefine the work classes and 
reset the work ctass of each process is neither required by 
togical ~ considerations nor justified by efficiency 
considerations. Furthermore such a primitive would not be able 
to handie an arbditrarity ftarge number of processes. 


In order to redefine the work ciasses In the general case, it 
wilt) be necessary first to define a transitional sef of work 
ciasses and percentages (including both ofd and =nynew work 
classes), then to reset the work class of each process to the 
new value, and finaity to define the new set of work classes. A 
procedure to do this will be implemented in the answering 
service. 


SUMMARY OF CURRENT LOAD CONTROL SOFTWARE 


Since work class membership wlll be a functlon of toad contro! 
group membership, work class definitions will be stored In the 
MGT, and the Implementation of the answering service and 
administrator interface to the priority scheduter wilt! consist 
mainty of modifications to the current toad controt software, a 
summary of that software, as it now exists, is presented here. 


Load control group membership is specified In the SAT entry for 
each project. In addition, each project*s SAT entry contains = an 
absotute max user figure for that project that Is enforced 
Independently of the foad control group timlts. 


Absentee and daemon processes are not subject to toad control. 
They are atways logged in on requeste They are assigned to the 
foad control group corresponding to their projects, but their 
group membershio is Ignored by everyone. 
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Load control groups are defined in the master_group_table (MGT), 
which Ils a binary table maintained by an editor (ed_mgt), and is 
not subject fo the instait disciptine. {413 This table contains 
timit parameters for each group, set by the system administrator, 
and it is also used to hold current toad figures for each group, 


during a session. 


The group timits are defined in units of user weight, rather than 
number of users. (There are, however, timits In units of users, 
for the system as a whofe, and for each project.) By default, 
each user has a welght of 10+ so max_units Is ten times 
max _userse Weight is a function of the process overseer, and Is 
determined by an array of weights keot in the SAT header. 


There are two sets of tilmit parameters per group, one used to 
compute primary_max_units, the other, to compute 
absotute_max_unifs. Each set contains three parameterst a 
constant (which may be zero), and a numerator and denominator of 
a fraction. The foraula for absolute_max_units for a group is? 


absotute_max_units = absolute_constant +t 
(avalliable_max_units*absotute_numerator) /absolute _denonmlnator 


where avallablte_max_unlits Is the system_max_units less the unlts 
used by the absentee and daemon processes who are not subject to 
foad control. The formula for primary_max_units is the same, but 
using prisgary_constant, primary numerator, and 
primary_denorminator. 


Tnese cafculations are performed for alt groups each time a user 
attempts to fog Ins so changes to units used by absentee or 
daemons, changes to system_max_unlts, or changes In the MGT made 
by the system administrator are att taken Into account 
immediatety. 


The system_max_units flgure is either: 
Le taken from the SAT header, for a special session, or 


Ze set by the operator, using the maxu command, in which case 
automatic maxunits setting Is turned off, or 


Ze set autoraticaliy at each shift change and whenever the maxu 
auto command is given by the operator. The automatic setting 
fooks up the current shift and configuration in the config 
array in installation_parms, and chooses the corresponding 


(1) The Instait disciptine is a method used for. instalting 
certain critical tables, whereby the Answering Service instalis 
the table, when requested by a system or project administrator, 
ensuring that the Answering Service wit! not attempt to reference 
the table white It Is being updated. 
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vaiues for system_max_units, max_absentee_users, 
max_absentee_queue, and response_high and response_tow. (The 
fatter two figures are used by the toad leveter (when it Is 
enabied by the maxu tftevel command), which readjusts 
syStem_max_units at every 15-minute accounting update, to 
keep response between the high and tow figures.) 


The toad control. decision is rather complex, when special 
privileges tike guaranteed toging the nobump attribute, and 
protection from preemption for a specified grace time are taken 
into account. But baslcaiiy, if the system is full (as measured 
by system_max_units or system_max_users) then someone must be 
bumped or elise the user is refused togine If the system Is not 
full, but the group or the project Is full (as measured by the 
group’s absotute_max_units oor the project*’s max_users), then 
someone in the group or project must be bumped, or else the user 
is refused ftogin. If the group*s primary _max_units are att 
allocated but Its absolute_max_units are not, then the user is 
logged in as a secondary user, subject to preemption. Secondary 
users (ln any group) are the first to be bumped (oldest first) 
when some primary user wants to fog ins» followed by primary users 
(in the same group) whose grace time has expired, folfowed by 
practically anybody, when a user with the guaranteed togin 
attribute is trylng to fog ine — 8 7 oz 


The toad control group membership of a process never changes, but 
both the proportion of the avaliable_max_units that each group 
gets, and the number itself, can vary with the 
avalliable_max_units (which varies with snhlft, configuration, and 
absentee and daemon ioad), because of the max_unifs formula 
described above. 


NEW ANSWERING SERVICE AND ADMINISTRATOR INTERFACE 


The MGT wili be reformatted to hold work ciass definitions as 
welt) as foad control group definitions. Since there will be a 
maximum of 16 work classes, but there is currently no restriction 
on the number of load control groups, the new MGT will consist of 
a header, followed by a fixed-fength array of 16 work class 
definitions, followed by a varilable-tength array of load control 
group definitions. The header and the toad control | group 
definitions witt remain essentlalty unchanged, except that each 
foad control group definition witti contain two additional 
8-element arraySs specifying the work classes to which 
Interactlve and absentee users in that toad control group betong 
on each shift. 


One or amore toad controt groups can belong to each work class. 
The max_users and max units figures for each work class will be 
the sum of the corresponding figures for the load control! groups 
that make up the work classe The work class maxima will not 
actuality be computed and stored: anywhere by the answering 
service, but they willl be displayed by ed_mgt to assist the 
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system administrator In assigning reasonably consistent 
percentages to the work classes and max user and unlt figures to 
the load control groups. The normai operation of toad contro!. 
as described above, will timit the number of processes in each 
work class. 


The ed mgt command wit! be modified to be abie to store and 
modify the work class parameters, to verifys on request, the 
correctness, reasonableness, and consistency of work class 
parameters and the corresponding toad contro! group definitions, 
and to print work class definitions and a cross reference showlng 
the correspondence between foad control groups and work classes. 
The changes to ed_mgt are described in detail in a tater section. . 


The instalt command will be modifled (land a new procedure, 
up_mgt_s will be written) so that the MGT can be installed white 
the system is up and users are logged ine up_mgt_ wlil nave to, 
in generat, reset the work class of ali existing processes to the 
work ciass specified in the newly-instattied MGT. 


The answer table (and daemon and absentee user tables), and the 
create_info structure passed to hphcs_$create_proc, will nave a 
new varlable, work_class, added. 


foad_cti_$Stoad_cti_init will cali npncs_Sdeflne_work_classes, to 
define the work ciasses to be used by the scheduler, durlng 
answering service initlalization. (This call must be made before 
the daemons are togged in.) 


toad _cti_$Sset_maxunlts, which Is called at each shift change (as 
welt as during the second hatf of answering service 
initiatizatlons and whenever the operator command “maxu auto™ Is 
given) wilt redefine the work classes, as specifed for the 
current shift in the MGT, and will reset the work class of each 
existing process as required. 


Since the functlon of redefining the current work classes and 
resetting the work classes of at! existing processes must be 
performed both at shift change and whenever a nen MGT Is 
Instatled, it will be Impiemented as a separate procedure, caited 
in both situations. 


To support the assignment of work ctasses on the basis of person 
as welll as project, the SAT and POT, and the procedures which 
complie, edits, and Instait them, will be modified to allow a toad 
controt' group to be specified for an individual user rather than 
just for a whole project. 


A nen attribute, igroup (individual group), wllt be created. When 
that attribute is on in the SAT entry for a project, It permits 
the toad controf group for users on that project to be speclfiled 
in the PDT entry for any user on that project. (If that attribute 
is not on in the SAT entry, then all users on the project witli 
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continue fo betong to the toad control group specified in the 
project*s SAT enfry-) then the Igroup attribute is on In the POT 
entry for an individual user, it Indicates that a toad control 
group is specified in tnat user‘ts PDT entry. (If igroup is not 
on in a user*’s POT entrys that user wlil continue to be a member 
of the toad contro! group specified in the project"’s SAT entry.) 
The name of the individuat user*s toad controf group wilti be 
stored in a presently unused pad fleld In the POT entry. Thiss 
plus the use of igroup in the POT entry as a positive indication 
that a group is specified, wlll attow this change to be Instatted 
without requiring that any existing PDT*s be reformatted or 
reinstalled. 


ig.ctt_ will be modified to assign a toad controt group on the 
basis of person as well as project, as described above. 


fload.icti_ witt be modified to use the load controfi group of each 
process to assign It to the work class specifled in the MGT for 
absentee or interactive users in that group, on the current 
shift. (Daemon processes wilil be treated as Iinteractlve, for the 
purpose of work class assignment.) The asslgned work class wlll 
be stored in the answer table (or absentee or daemon user tabie) 
entry for the processe 


cpg_ will copy the work class from the answer table entry into 
the create_info structure, before calling nphcs_%create_proc. 


INSTALLATION PROCEDURE 


The hardcore system containing the oriority scheduter, and the 
answering service containing the above smodificatilons, can be 
instaited in eifher order. If hphcs_Sdefine_work_classes is not 
called, a single work class (work class 1) wlll) exist by default, 
and witl nave a percentage of 100%. The version number of the 
create Info structure wilt attow act_proc (the ring zero 
procedure called vla hphcs_$create_proc) to determine if the new 
version, containing the work class, has been passed. If the old 
version of create_Info is used, act_proc wlil assign processes to 
work class i by default. This atlows the hardcore system to be 
instatied first. 


The new answering service wlll check for the otd format MGT, and 
lf it is founds none of tne new gates will be called, and every 
process wa#ltt be assigned to work class 1+ independent of their 
load controt group membership. Further, a switch In the 
reformatted MGT, settable by ed_mgt, will alion this mode of 
operatlon to be specifled by the system administrator after the 
MGT Is reformatted. Finally, a check for the existence of 
hphcs_Sdefine_work_ciasses wll! be made during answering service 
initialization, and if it is not present, the old mode of 
operation wllf be usede This wil! make the new answering service 
compatibie with oider system tapes. It wilt! aiso cause the 
system to run as it does now, with onty one work class, when both 
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”w answering service and the new hardcore system are 
ede The new scheduter wllt not be turned on until! the M6T 
rmatted, and the system administrator expticitty enables 


The system administrator witt, of course, be Informed of atl this 
in release documentation. The first time ne uses the new ed mgt, 
it. wilt! recognize the old format MGT, reformat it automatically, 
deflne a single work class (work class 1) wlth a percentage of 
100%, make all toad control groups members of it, and then invite 
the system admlnistrator to define more work classes and reassign 
the toad controt groups to them. I[t will not be required that 
the administrator do so, but ed_mgt wilt keep reminding him, 
every time he uses If, untli he does. 


Since the MGT wilt! now be subject to the Install disciptine, the 
reformatted copy can not be put back In >scie When the “w"™ 
request is givens the reformatted MGT (named MGT.mgt) wlit be 
written in the working directory of the administrator (which 
Should be  >udd>sar>admin). The administrator will be told about 
this by ed_agt. Except for the Instance when the MGT Is 
reformatted, the edited MGT wlll! be written back Into the Input 
MGT+s as Is done now. However, the system administrator wltit not 
be editing the »>scit1 copy any more. As a convenlence, after 
writing the edited copy back into the original, edimgt will 
always ask “Instait?“, and If the answer Is yes, It will Invoke 
the Iinstalt command. The administrator will of course be able to 
Invoke it directty. 


The Instatiation procedures described above wilt make testing and 
initial instattiation of the system very convenient, and it wil! 
also allow the system administrator at each customer site to turn. 
on the priority scheduler at his convenience, instead of forcing 
him to define some (posslibiy Ltt-considered) work classes, just 
to get the new system retfease to run. 


CHANGES T0 ed_agft 
Summary of Current ed_agt 


The fotiowing summary describes only those features that are 
belng changed. The MGT, as seen by a user of ed_mgt, Is an array 
of toad control group definitlonse Tne find (f) request positions 
the current pointer to the specified groupe The next (n), top 
(t), and - (minus sign) requests move the current pointer forward 
or backward in the arraye The change (c) request changes 
parameters of the current group. The print (p) request prints all 
information about the current group. The pal! (pa, p*) request 
prints al! information about all groups. Only the find and change 
requests take arguments. Their formats are’ 


find <group name> 
change <code> <new value> (<code> <new value> ...)] * 
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where <code> is fhe name of the parameter to be changed. Typing 
these requests without arguments causes ed_mgt to prompt the user 
for them. The change request puts ed_mgt into the change 
subcommand, in which <code> <new value> pairs are accepted. The 
asterisk at the end of the tine exits from the change subcommand 
and returns to ed_mgt request tevel. 


Summary of New Features 


The find request will be modifled so that a <group name> 
consisting of one of tne integers 1 through 16 will refer to the 
corresponding work class. 


The nexts top, and - requests will be modified to print the name 
and type of the entry being polnted at after the pointer Is 
movede 


The change request will be modified so that the set of codes 
accepted wilt be dilfferent, depending on which type of entry 
(work class or toad controt. group) the current pointer is 
pointing at. New codes and other arguments willl be added, to 
ailtow parameters of work classes, and the work class membership 
of toad contro! groups, to be edited. . 


A new requests global_change (9c), will be added, to allow the 
same (set of) changels) to be made to all’ work classes or to alt. 
foad control! groups. 


A new request, verify (v), wlll be added, to request that ed_mgt 
check all the work-ciass-related parameters in the edited MGT, 
and report any errors or warnings that would be recelved If the 
MGT were to be instalfed. 


The print and pall requests will be changed to print the new 
parameters, and the palt request wilt) take arguments, requesting 
that all work classes, or all toad controi groups, or both, be 
printed, or that a cross reference of work classes and toad 
controt groups be printed. 
Detailed Descriotions of New Features 
Two new formats for the change request willl be added? 

change <code> [<shift speclificatlon>) <one or amore vatues> 


change <code> [<shifft spec.>] <interactivelabsentee> <vaiue(s)> 


The first Is used when editing work class parameters; the second, 
white changing the work class membership of a toad contro! group. 
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The following new <code>*s can be used in the above requests? 


percent foct; 2%) 


absentee (abs) 
defined (def) 
work class (we) 


The first three are used with the first form of the change 
request, to edit work class parameters. The fourth Is used with 
the second form, to change the work class membership of aie toad 
control group. 


The format of the <shift specification> is the word “shift™ 
followed by a shift number or a range of shift numbers (two 
numbers separated by a hyphen, the second greater than the 
first): 


shlft <number>!<number>-<number> 


The shlft specification is optionat. If It is omitted, the 
default is aefunctlon of how many vatues are supplied. If one 
vaiue Is suppiled, it is assigned to all 8 shifts. If a list of 
values is supplied, they are assigned to shifts 0s 1:2 eess 
respectively, and shifts for which values are not supplied are 
not changed. 


The following relationship exists between the shift speci fication 
and the tist of vaiues? when a range of shifts is specified, a 
single data value Is expected, and Is assigned to all shifts In 
that ranges when a singie shift is speclfled, one or more vatues 
may be supptled, and they are assigned to shifts, in order, 
starting with the specifled shift. 


<interactivelabsentee> can bet 


Interactive (int) 
absentee (abs) 


This argument is used when setting the work class of a toad 
control groupe Separate work classes may be specifled (for 
interactive and absentee processes In the foad control group, on 
each shift. If this argument is omitted, but the work class 
value(s) are glven, the default is interactive. 


The work class parameters “defined” and “absentee” can have 
values of “off™ or “on™ (or “0% or 1"). ‘They are per-shift 
switches, that Indlcate respectivety, whether the work class is 
defined on the given shift, and whether abdsentee processes are 
permitted in it on that shift. 
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Tne format of the gtobai_change request will bet 
gc <type> <arguments acceptabie to the change request> 
where <type> can be? 


load _controalt_group (Cicg) 
work_class (wo) 


The effect of this command wil! be to make each change (specified 
by a change subcommand) to afl entries of the specified type. 


The format of the palit (print att) request will bes 
pali <type> 

where <fype> can be? 
foad_control group (icg) 
work_class (ac) 


cross_reference {cref, xref) 


If <type> is omitted, the default will be to print all three sets. 
of information. 


Examples’ 
change 410. - 
change 4% shift 0 10 10 40 109 10 10101060. 
change pct shift 0-7.10. 


The above are equivatent ways of assigning 10% to the current 
work ciass on alti shifts. | 


change Z shlft 1 50 % shift 2-4 30 . 
The above request is equivalent to the following two requests’ 


change % shift i 50 . 
change Z shift 2-4 30 . 


c we Int shlft 1 3 we shift 2-4 Int 2 wc abs i. 


The above sets the Interactive work class of the current toad 
controi group to 3 on shift 41 and to 2 on shiffs 2-4, and the 
absentee work class on ali 8&8 shifts to 1- Notice that the shift 
specification and the Interactivelabdsentee Indicator may appear 
in elther order. 


gc we defined shift 0 off defined snift 5-7 off . 


The above willl set alll work classes to undefined except on shifts 
i7-4&. This would be useful at an Instaltatlon where onty shifts 
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i-4& were In uses to simpilfy the output of the print and pali 
commands, since informatlon about undefined shifts Is not 
nrintad. 

Note that, In the examples, a perlod Is used to terminate the 
change request tines Instead of an asterisk. In the new ed_mgt, a 
perlod wilt be accepted for that function, in addition to an 
asterisk, for conmpatiblilty with other Muttics editors. 


The examples Show alt required arguments supptiied on a single 
line. ed_mgt will proapt for missing values. The example above, 
in which the percents for shifts 1 and 2-4 were changed, would 
took tike this If the user typed onty what was requested (! 
Indicates prompting messages) 3 


q types 
change 

4 code’ 
% 

g shifts 
1 

bf vafue(s)3 
50 

q code’ 
% 

t shifts 
2-4 

q value! 
30 

t code? 


